XML Output Formats
XML Output Formats
 
This appendix provides information about the various eXtensible Markup Language (XML) file format definitions in the Bulkstat server. The XML file format definition is based on XML schema. The 3GPP standards are followed to generate XML report files in the XML report generator. These defined file format definitions correspond to each other (except for some minor XML specific optimizations).
This chapter includes the following topics:
•
Supported XML Output Formats
•
Examples of XML Output Formats
•
File Naming Conventions
•
Supported Standards
•
Understanding WEM Bulk Statistics Output in XML Reports
note_smallImportant: Unless otherwise specified, all information in this chapter applies to both Sun Solaris- and Red Hat Enterprise Linux-based WEM systems.
Supported XML Output Formats
The following XML output formats are supported:
•
DTD Based Format: This format is DTD based and it can be enabled/disabled using the configurable parameter, ‘XMLFileFormat’ provided in the configuration file bsserver.cfg in the /<ems_dir>/etc directory.
•
3GPP Format: This is the new and default 3GPP recommended format to generate the XML report file. This format reduces the XML file size.
WEM generates two types of files for the above two formats. These are individual XML files for all subsystems and single XML file for all subsystems which can be configured using the parameter ‘XMLFileType’ in the bsserver.cfg file.
Refer Appendix B for information on the configurable parameters in the bsserver.cfg file.
Examples of XML Output Formats
This section provides the sample outputs for the DTD based and 3GPP XML formats.
DTD Based Format
This following output is an example of individual files for all subsystems in DTD based XML format.
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<!DOCTYPE mdc SYSTEM "MeasurementStat.dtd">
<?xml-stylesheet type="text/xsl" href="simple_table.xsl" ?>
<mdc>
<mfh>
<ffv>2</ffv>
<sn>Starent Network Inc.</sn>
<st>MSC</st>
<vn>Samsung corp.</vn>
<cbt>2006-01-03 13:10:00</cbt>
</mfh>
<md>
<neid>
<neun></neun>
<nedn></nedn>
<nesw></nesw>
</neid>
<mi>
<mts>2006-01-03 13:15:00</mts>
<gp>300</gp>
<rsf>false</rsf>
<ms>
<msn>CardStat</msn>
<sf>false</sf>
<es>false</es>
<mt p="0">card</mt>
<mt p="1">cpubusy</mt>
<mt p="2">cpuidle</mt>
<mt p="3">numproc</mt>
<mt p="4">memused</mt>
<mt p="5">memtotal</mt>
<mv>
<moid> card=17 </moid>
<r p="0">6</r>
<r p="1">0.76</r>
<r p="2">99.24</r>
<r p="3">158</r>
<r p="4">1057704</r>
<r p="5">4194304</r>
</mv>
<mv>
<moid> card=8 </moid>
<r p="0">8</r>
<r p="1">0.45</r>
<r p="2">99.55</r>
<r p="3">65</r>
<r p="4">306512</r>
<r p="5">1048576</r>
</mv>
</ms>
</mi>
</md>
<mff>
<ts>2006-01-03 13:15:00</ts>
</mff>
</mdc>
This following output is an example of all subsystems in a single file in DTD based XML format.
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<!DOCTYPE mdc SYSTEM "MeasurementStat.dtd">
<?xml-stylesheet type="text/xsl" href="simple_table_all.xsl" ?>
<mdc>
<mfh>
<ffv>2</ffv>
<sn>Starent Network Inc.</sn>
<st>MSC</st>
<vn>Samsung corp.</vn>
<cbt>2006-01-03 13:10:00</cbt>
</mfh>
<md>
<neid>
<neun></neun>
<nedn></nedn>
<nesw></nesw>
</neid>
<mi>
<mts>2006-01-03 13:15:00</mts>
<gp>300</gp>
<rsf>false</rsf>
<ms>
<msn>CardStat</msn>
<sf>false</sf>
<es>false</es>
<mt p="0">card</mt>
<mt p="1">cpubusy</mt>
<mt p="2">cpuidle</mt>
<mt p="3">numproc</mt>
<mt p="4">memused</mt>
<mt p="5">memtotal</mt>
<mv>
<moid> card=17 </moid>
<r p="0">17</r>
<r p="1">0</r>
<r p="2">100</r>
<r p="3">0</r>
<r p="4">0</r>
<r p="5">0</r>
</mv>
<mv>
<moid> card=8 </moid>
<r p="0">8</r>
<r p="1">0.45</r>
<r p="2">99.55</r>
<r p="3">65</r>
<r p="4">306512</r>
<r p="5">1048576</r>
</mv>
</ms>
<ms>
<msn>PortStat</msn>
<sf>false</sf>
<es>false</es>
<mt p="0">card</mt>
<mt p="1">port</mt>
<mt p="2">rxbytes</mt>
<mt p="3">txbytes</mt>
<mt p="4">ucast_inpackets</mt>
<mt p="5">ucast_outpackets</mt>
<mt p="6">mcast_inpackets</mt>
<mt p="7">mcast_outpackets</mt>
<mt p="8">bcast_inpackets</mt>
<mt p="9">bcast_outpackets</mt>
<mt p="10">rxpackets</mt>
<mt p="11">txpackets</mt>
<mt p="12">rxdiscbytes</mt>
<mt p="13">rxdiscpackets</mt>
<mt p="14">txdiscbytes</mt>
<mt p="15">txdiscpackets</mt>
<mt p="16">maxrate</mt>
<mt p="17">frag-rcvd</mt>
<mt p="18">pkt-reassembled</mt>
<mt p="19">frag-tokernel</mt>
<mv>
<moid> card=17,port=1 </moid>
<r p="0">17</r>
<r p="1">1</r>
<r p="2">43346</r>
<r p="3">1792</r>
<r p="4">328</r>
<r p="5">28</r>
<r p="6">0</r>
<r p="7">0</r>
<r p="8">1</r>
<r p="9">0</r>
<r p="10">329</r>
<r p="11">28</r>
<r p="12">0</r>
<r p="13">0</r>
<r p="14">0</r>
<r p="15">0</r>
<r p="16">0</r>
<r p="17">0</r>
<r p="18">0</r>
<r p="19">0</r>
</mv>
</ms>
<ms>
<msn>IPPoolStat</msn>
<sf>false</sf>
<es>false</es>
<mt p="0">vpnname</mt>
<mt p="1">vpnid</mt>
<mt p="2">name</mt>
<mt p="3">used</mt>
<mt p="4">hold</mt>
<mt p="5">release</mt>
<mt p="6">free</mt>
<mt p="7">type</mt>
<mt p="8">priority</mt>
<mt p="9">state</mt>
<mv>
<moid> vpnname=network,vpnid=2,name=Pool </moid>
<r p="0">network</r>
<r p="1">2</r>
<r p="2">Pool</r>
<r p="3">0</r>
<r p="4">0</r>
<r p="5">0</r>
<r p="6">254</r>
<r p="7">S</r>
<r p="8">0</r>
<r p="9">G</r>
</mv>
</ms>
</mi>
</md>
<mff>
<ts>2006-01-03 13:15:00</ts>
</mff>
</mdc>
3GPP Format
This following output is an example of individual files for all subsystems in 3GPP XML format.
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<!--?xml-stylesheet type="text/xsl" href="MeasDataCollection.xsl?"-->
<measCollecFile xmlns="http://www.3gpp.org/ftp/specs/archive/32_series/32.435#measCollec" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.3gpp.org/ftp/specs/archive/32_series/32.435#measCollec http://www.3gpp.org/ftp/specs/archive/32_series/32.435#measCollec">
<fileHeader dnPrefix="Unknown" fileFormatVersion="2" vendorName="Sagar">
<fileSender elementType="Nikhil" localDn="Same"/>
<measCollec beginTime="2008-04-25 04:40:00"/>
</fileHeader>
<measData>
<managedElement localDn="Same" swVersion="7.1.19504" userLabel="st16"/>
<measInfo>
<job jobId="7381"/>
<granPeriod duration="PT300S" endTime="2008-04-25 04:45:00"/>
<msn>CardStat</msn>
<suspect>false</suspect>
<measTypes>card cpubusy cpuidle numproc memused memtotal</measTypes>
<measValue measObjLdn="card=22">
<measResults>22 0 100 0 0 0</measResults>
</measValue>
<measValue measObjLdn="card=24">
<measResults>24 0 100 0 0 0</measResults>
</measValue>
</measInfo>
</measData>
<fileFooter>
<measCollec endTime="2008-04-25 04:45:00"/>
</fileFooter>
</measCollecFile>
This following output is an example of all subsystems in a single file in 3GPP XML format.
<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<!--?xml-stylesheet type="text/xsl" href="MeasDataCollection.xsl?"-->
<measCollecFile xmlns="http://www.3gpp.org/ftp/specs/archive/32_series/32.435#measCollec" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.3gpp.org/ftp/specs/archive/32_series/32.435#measCollec http://www.3gpp.org/ftp/specs/archive/32_series/32.435#measCollec">
<fileHeader dnPrefix="Unknown" fileFormatVersion="2" vendorName="Sagar">
<fileSender elementType="Nikhil" localDn="Same"/>
<measCollec beginTime="2008-04-25 04:40:00"/>
</fileHeader>
<measData>
<managedElement localDn="Same" swVersion="7.1.19504" userLabel="st16"/>
<measInfo>
<job jobId="7381"/>
<granPeriod duration="PT300S" endTime="2008-04-25 04:45:00"/>
<msn>CardStat</msn>
<suspect>false</suspect>
<measTypes>card cpubusy cpuidle numproc memused memtotal</measTypes>
<measValue measObjLdn="card=22">
<measResults>22 0 100 0 0 0</measResults>
</measValue>
<measValue measObjLdn="card=24">
<measResults>24 0 100 0 0 0</measResults>
</measValue>
<msn>PortStat</msn>
<suspect>false</suspect>
<measTypes>card port rxbytes txbytes ucast_inpackets ucast_outpackets mcast_inpackets mcast_outpackets bcast_inpackets bcast_outpackets rxpackets txpackets rxdiscbytes rxdiscpackets txdiscbytes txdiscpackets maxrate frag-rcvd pkt-reassembled frag-tokernel</measTypes>
<measValue measObjLdn="card=22,port=1">
<measResults>22 1 1236 1024 16 16 0 0 2 0 18 16 0 0 0 0 100000000 0 0 0</measResults>
</measValue>
<measValue measObjLdn="card=22,port=2">
<measResults>22 2 212 0 0 0 0 0 2 0 2 0 0 0 0 0 100000000 0 0 0</measResults>
</measValue>
<msn>IPPoolStat</msn>
<suspect>false</suspect>
<measTypes>vpnname vpnid name startaddr groupname used hold release free type priority state</measTypes>
<measValue measObjLdn="vpnname=egress,vpnid=6,name=dynamic,startaddr=17.0.0.1,groupname=">
<measResults>egress 6 dynamic 17.0.0.1 0 0 0 65534 P 0 G</measResults>
</measValue>
<measValue measObjLdn="vpnname=egress,vpnid=6,name=static,startaddr=18.0.0.1,groupname=">
<measResults>egress 6 static 18.0.0.1 0 0 0 65534 S 0 G</measResults>
</measValue>
</measInfo>
</measData>
<fileFooter>
<measCollec endTime="2008-04-25 04:45:00"/>
</fileFooter>
</measCollecFile>
File Naming Conventions
The naming conventions for the files are as per 3GPP standard. The naming convention is different only for individual subsystem files where we include subsystem names in the file name (for example, “CardStat”, “PortStat”, etc.).
The following convention will be applied for measurement result file naming:
<Type><Startdate>.<Starttime>-[<Enddate>.]<Endtime>_[<UniqueId>][:<RC>]
Field Name
Description
Type
Indicates if the file contains measurement results for single or multiple NEs and/or granularity periods, where:
•
“A” indicates single NE, single granularity period;
•
“B” indicates multiple NEs, single granularity period;
•
“C” indicates single NE, multiple granularity periods;
•
“D” indicates multiple NEs, multiple granularity periods.
Startdate
Indicates the date when the granularity period began if the Type field is set to “A” or “B”. If the Type field is either “C” or “D” then, Startdate contains the date when the first granularity period of the measurement results contained in the file started. The Startdate field is of the form YYYYMMDD, where:
•
YYYY is the year in four digit notation;
•
MM is the month in two digit notation (01-12);
•
DD is the day in two digit notation (01-31).
Starttime
Indicates the time when the granularity period began if the Type field is set to A or B. If the Type field is either “C” or “D” then, Starttime contains the time when the first granularity period of the measurement results contained in the file began. The Starttime field is of the form HHMMshhmm, where:
•
HH is the two digit hour of the day (local time), based on 24 hour clock (00-23);
•
MM is the two digit minute of the hour (local time), possible values are 00, 05, 10, 15, 20, 25, 30, 35, 40, 45, 50, and 55;
•
s is the sign of the local time differential from UTC (+ or -), in case the time differential to UTC is 0 then the sign may be arbitrarily set to “+” or “-”;
•
hh is the two digit number of hours of the local time differential from UTC (00-23);
•
mm is the two digit number of minutes of the local time differential from UTC (00-59).
Enddate
This field will only be included if the Type field is set to “C” or “D”, that is, measurement results for multiple granularity periods are contained in the file. It identifies the date when the last granularity period of these measurements ended, and its structure corresponds to the Startdate field.
Endtime
Indicates the time when the granularity period ended if the Type field is set to A or B. If the Type field is either “C” or “D” then, Endtime contains the time when the last granularity period of the measurement results contained in the file ended. Its structure corresponds to the Starttime field, however, the allowed values for the minute of the hour are 05, 10, 15, 20, 25, 30, 35, 40, 45, 50, 55, and 00.
UniqueId
This is the name of the NE, EM or domain (for example, a distinguishedName). The field may be omitted only if the distinguishedName is not available from the CM applications.
RC
This parameter is a running count, starting with the value of “1”, and will be appended only if the filename is not unanimous, that is, more than one file is generated and all other parameters of the file name are identical. Therefore, it may only be used by the Network Element Manager (EM), since the described situation can not occur with Network Element (NE) generated files.
‌
A few examples describing the file naming convention are as follows:
•
File name: A20000626.2315+0200-2330+0200_NodeBId;
Meaning: File produced by NodeB <NodeBId> on June 26, 2000, granularity period 15 minutes from 23:15 local to 23:30 local, with a time differential of +2 hours against UTC.
•
File name: B20021224.1700-1130-1705-1130_EMId,
Meaning: File containing results for multiple NEs, produced by EM <EMId> on December 24, 2002, granularity period 5 minutes from 17:00 local to 17:05 local, with a time differential of –11:30 hours against UTC.
•
File name: D20050907.1030+0000-20050909.1500+0000_DomainId:2,
Meaning: File containing results for NEs belonging to domain <DomainId>, start of first granularity period 07 September 2005, 10:30 local, end of last granularity period 09 September 2005, 15:00 local, with a time differential of 0 against UTC. This file is produced by the EM managing the domain, and it is the second file for this domain/granularity periods combination.
Supported Standards
WEM complies with the following 3rd Generation Partnership Project (3GPP) standards for generation of XML report files in DTD based format and 3GPP format respectively.
•
3GPP TS 32.401 V4.1.0 (2001-12): “Concept and Requirements”
•
3GPP TS 32.435 V6.2.0 (2006-03): “Performance measurement: eXtensible Markup Language (XML) file format definition”
Understanding WEM Bulk Statistics Output in XML Reports
WEM can be configured to generate bulk statistics reports in XML format at user-defined intervals. The reports generate statistical output based on the bulk statistic type (Counter or Gauge) and its availability (e.g., per context, per service, per APN or across all services on the system). For bulk statistics of type “Incremental,” WEM will calculate and generate a delta value. For bulk statistics of type “Gauge,” WEM always provides the absolute value.
note_smallImportant: A bulk statistic type of 'Counter' is referred to as an 'Incremental Counter' in WEM files.
How WEM Parses Bulk Statistic Data
The ASR 5000 chassis keeps a running aggregate total of bulk statistics configured for collection. The total continues to increase until the counters are cleared or the chassis is reset. However, the XML reports generated by WEM do not provide a running aggregate total for each statistical value of a counter of type “Incremental.” Instead, WEM performs a calculation on each bulk statistic counter configured for the XML report so that only the incremental value for a configured time interval appears in the generated report.
Once bulk statistic generation is enabled, WEM uses the first configured report interval to obtain the raw statistical value for each configured bulk statistic. This first group of statistical values will be used by the system as a reference value for each of the bulk statistics configured to appear in the report. WEM does not generate a report based on this first group of reference values.
When the second configured report interval is reached, WEM obtains the raw statistical value from the ASR 5000 chassis, compares those values to the reference values obtained from the first interval, and outputs the delta to the XML report. This process continues for each scheduled time interval, with the latest interval’s statistical output being compared against the previous one, and the delta being generated in succeeding XML reports.
note_smallImportant: WEM must be able to reference two consecutive bulk statistics collection records before it can generate an XML report. If two consecutive records are not found, WEM does not generate a report.
Example
In this example, a WEM user has enabled bulk statistic collection to occur at 15-minute intervals beginning at 11:00. WEM will then use the information gathered from the ASR 5000 to calculate the incremental totals for each 15-minute interval and output them to reports in XML format.
1.
At 11:00, WEM stores the raw statistical reference value for the bulk statistics obtained from the ASR 5000. An XML report is not generated.
2.
At 11:15, WEM obtains the raw statistical bulk statistics values for counters of type Incremental and Gauge from the ASR 5000 and compares these to the values obtained at 11:00.
3.
For bulk statistics of counter type Incremental, WEM subtracts the stored statistical values of the 11:00 collection from the values obtained at the 11:15 collection. The deltas between the two sets of values are then generated in the XML report. For bulk statistics of type Gauge WEM performs no delta calculation and outputs the absolute value to the XML report.
4.
During each of the succeeding report intervals, WEM obtains the raw statistical values of counter type “Incremental” from the chassis and subtracts the previous report’s value from them to calculate and generate the XML output. Bulk statistics of type “Gauge” are always generated as absolute values.
Example: Incremental Bulk Statistic Calculations for a WEM XML Report
Report Number
Time
Raw Bulk Statistic Value
Value Generated in XML Report
n/a
11:00
100
Raw reference value obtained. No XML report is generated.
1
11:15
200
100 (200-100=100)
2
11:30
400
200 (400-200=200)
3
11:45
1000
600 (1000-400=600)
4
12:00
1500
500 (1500-1000=500)
‌
Sample XML Bulk Statistics Report
The generated XML report includes the following information:
•
Start and end time of the bulk statistic collection interval.
•
The granularity period for bulk statistics collection (in seconds).
•
The bulk statistic variable names that have been configured to appear in the report.
•
The context, session, service name or APN name associated with the collected bulk statistics. The identifiers available will vary depending on the bulk statistic schema for which statistics are being collected.
•
The values for bulks statistics of counter types Incremental and Gauge.
Example WEM XML Report (3GPP 6.2.0 Format)
 
 
Cisco Systems Inc.
Tel: 408-526-4000
Fax: 408-527-0883